HuijingHei [Mon, 4 Mar 2024 02:44:42 +0000 (10:44 +0800)]
kargs: parse spaces in kargs input and keep quotes
According to Jonathan's suggestion, should fix the code from
ostree repo.
With this patch:
- kargs input like "init_on_alloc=1 init_on_free=1", will be
parsed as 2 seperated args `init_on_alloc=1` and `init_on_free=1`,
instead of whole;
- According to https://www.kernel.org/doc/html/v4.14/admin-guide/kernel-parameters.html,
need to keep spaces in double-quotes, like `param="spaces in here"`
will be parsed as whole instead of 3.
Colin Walters [Wed, 28 Feb 2024 14:40:34 +0000 (09:40 -0500)]
sysroot: Turn on bootloader-naming-2 by default
I think it's about time we flipped this on by default;
like the bootprefix I was a bit too chicken. We still have
a `bootloader-naming-1` that can be flipped on in case of
some regression.
Colin Walters [Tue, 27 Feb 2024 18:14:16 +0000 (13:14 -0500)]
bootloader/grub2: Don't do anything if we have static configs
This builds on top of https://github.com/coreos/bootupd/pull/609/commits/fa9924e4fe403c3751392c041cd98614a2cc3611
(But in a very hacky way because we don't currently link to a JSON library)
Basically, bootupd supports injecting static configs, and this
is the currently least hacky way for us to detect this and understand
that we shouldn't try to run `grub2-mkconfig`.
A further patch I'd like to do here is also change the probing
logic to gracefully no-op if `grub2-mkconfig` doesn't exist,
but that has a bit more risk and involvement.
Colin Walters [Tue, 27 Feb 2024 15:59:02 +0000 (10:59 -0500)]
otcore: Drop config load print
Now that we're using `otcore_load_config` from the deploy
path we end up printing to stdout even for API callers (e.g.
our own CLI tools, and rpm-ostree/bootc/etc) which is wrong.
Dan Nicholson [Tue, 27 Feb 2024 15:41:46 +0000 (08:41 -0700)]
main: Ignore SIGPIPE when printing version
In order to do a runtime feature check, `ostree --version` can be piped
to `grep` or similar. However, if the read end of the pipe doesn't read
all of the output, `ostree` will receive `SIGPIPE` when trying to write
output. Ignore it so that `ostree` still exits successfully in that
case.
Eric Curtin [Thu, 22 Feb 2024 18:15:09 +0000 (18:15 +0000)]
sysroot: Reword comment and use gboolean over bool, error handling
Be more explicit in the comment, and use gboolean over bool. Less header
inclusions when we use gboolean. Although bool is used in some places.
Write a separate _ostree_sysroot_parse_bootlink_aboot function for
aboot. Make is_aboot optional. Handle invalid androidboot karg and no
ostree and androidboot kargs differently.
Co-authored-by: Jonathan Lebon <jonathan@jlebon.com> Signed-off-by: Eric Curtin <ecurtin@redhat.com>
prepare-root: Disallow hotfixes if using signed composefs images
As mentioned in https://github.com/ostreedev/ostree/issues/3187, we
can't allow a hotfix overlay of /usr when using signed composefs
images as that would allow an attacker to persist something used
across boots.
Eric Curtin [Wed, 21 Feb 2024 16:02:08 +0000 (16:02 +0000)]
generator: Fixes for Android Boot environment
In Android Boot environment we do not parse ostree= karg to determine
what directory to boot into, alternatively we do this based on the
androidboot.slot_suffix= karg. But we do set ostree=true karg to denote
that we are indeed booting an ostree environment (required for some
systemd unit files). This change accounts for this approach in the
systemd generator. In this case androidboot.slot_suffix= points you to
/ostree/root.[a|b] and then that points you to the directory to boot
into in /ostree/deploy... Here is what a cmdline may look like in this
type of environment:
deploy: Don't fail if loading composefs configuration fails due to missing keys
When we load the configuration during deploy we don't need to actually
use the keys, so avoid loading them. This fixes an issue we had where
this broke the initial deploy becasue of a failure to load the key. In
our case it fails because the code looks for the config file in the
deploy dir, but then for the binding key in the real root.
However, even if it were to look for the key in the deploy dir I don't
think it necessarily has to be in the rootfs, it could be only in the
initrd.
This fixes https://github.com/ostreedev/ostree/issues/3188
Simon McVittie [Mon, 19 Feb 2024 16:07:13 +0000 (16:07 +0000)]
tests: Use skip_without_ostree_feature to detect libarchive, composefs
This avoids false negatives from `ostree --version | grep -q ...`
exiting with failure under `set -o pipefail` because `grep -q` can exit
as soon as it sees the desired string, leaving `ostree --version` to be
terminated by `SIGPIPE` next time it writes to stdout.
Signed-off-by: Simon McVittie <smcv@collabora.com>
Eric Curtin [Sat, 17 Feb 2024 17:12:19 +0000 (17:12 +0000)]
README: Add Red Hat In-Vehicle Operating System
RHIVOS is a derivative of CentOS Automotive Stream Distribution that
uses OSTree, it's closest Fedora derivative is Fedora IoT although it
was created as it's own distribution.
Colin Walters [Tue, 13 Feb 2024 20:41:35 +0000 (15:41 -0500)]
prepare-root: Switch to a tmpfs for transient root
We're debating this over in https://github.com/CentOS/centos-bootc-dev/pull/27
and I have come to the conclusion that having changes to `/`
persist across reboot by default was a bad idea.
- It conflicts with any kind of secure boot scenario
- Having things only go away on upgrades is in some ways even *more* surprising
- The term `transient` implies this
There may be a use case in the future for having something like `root.transient = persistent`,
but this is just a better default.
Colin Walters [Mon, 12 Feb 2024 22:24:10 +0000 (17:24 -0500)]
prepare-root: Unify root.transient with composefs
First, I was totally wrong and composefs handles being passed
an upperdir itself, we don't need to stack overlayfs.
Next, there's really no reason to support `root.transient`
*without* a backing composefs. The legacy ostree bind mount
and readonly `/usr` is just that - legacy.
Finally, we actually *must* do this to enable both composefs
and transient root, because the prepare-root flow assumes
that it just needs to `MS_MOVE` a *single* mount for the root,
not a stack.
Colin Walters [Fri, 9 Feb 2024 19:44:43 +0000 (14:44 -0500)]
sysroot: Rework /var handling to act like Docker `VOLUME /var`
We've long struggled with semantics for `/var`. Our stance of
"/var should start out empty and be managed by the OS" is a strict
one, that pushes things closer to the original systemd upstream
ideal of the "OS state is in /usr".
However...well, a few things. First, we had some legacy bits
here which were always populating the deployment `/var`. I don't
think we need that if systemd is in use, so detect if the tree
has `usr/lib/tmpfiles.d`, and don't create that stuff at
`ostree admin stateroot-init` time if so.
Building on that then, we have the stateroot `var` starting out
actually empty.
When we do a deployment, if the stateroot `var` is empty,
make a copy (reflink if possible of course) of the commit's `/var`
into it.
This matches the semantics that Docker created with volumes,
and this is sufficiently simple and easy to explain that I think
it's closer to the right thing to do.
Crucially...it's just really handy to have some pre-existing
directories in `/var` in container images, because Docker (and podman/kube/etc)
don't run systemd and hence don't run `tmpfiles.d` on startup.
I really hit on the fact that we need `/var/tmp` in our container
images by default for example.
So there's still some overlap here with e.g. `/usr/lib/tmpfiles.d/var.conf`
as shipped by systemd, but that's fine - they don't actually conflict
per se.
Colin Walters [Thu, 8 Feb 2024 15:13:57 +0000 (10:13 -0500)]
Track deployment root/inode from prepare root
When we added composefs, it broke the logic for detecting the booted
deployment which was previously a direct (device, inode) comparison.
So the code there started looking at `etc`. However, that in
turns breaks with `etc.transient = true` enabled.
Fix all of this by tracking the real deployment directory's
(device,inode) that we found in `ostree-prepare-root`, and inject
it into the extensible metadata we have in `/run/ostree-booted`
which is designed exactly to pass state between the initramfs
and the real root.
Michael Vogt [Wed, 31 Jan 2024 17:02:24 +0000 (18:02 +0100)]
libostree: write selinux xattr when on non-selinux systems
Currently when writing data for selinux systems on a non-selinux
system there will be no labels. This is because
`ostree_sepolicy_setfscreatecon()` just returns TRUE on non-selinux
systems and xattr writing for `security.seliux` is filtered out.
This patches uses the suggestion of Colin Walters (thanks!) from
https://github.com/ostreedev/ostree/issues/2804 and detects if
the host has selinux enabled and if not just skips filtering the
xattrs for selinux.
See discussion in https://github.com/ostreedev/ostree/pull/3156 ;
we think this breaks s390x in some cases at least, and that warrants
further investigation.
Colin Walters [Mon, 5 Feb 2024 19:14:27 +0000 (14:14 -0500)]
Enable `sysroot.bootprefix` by default
I've been testing this in various places and not seen any fallout,
so let's finally enable this by default and have the situation where
`/boot` is on the root `/` filesystem work out of the box.
Jonathan Lebon [Tue, 6 Feb 2024 19:42:32 +0000 (14:42 -0500)]
generator: Restore graceful exit behaviour if `ostree` karg missing
In CoreOS live environments, we do have `/run/ostree` but no `ostree=`
karg; we hackily fool `ostree-prepare-root.service` by bind-mounting
over `/proc/cmdline` so it does the right thing. Presumably, we should
clean this up eventually, but even so we don't want to require PXE users
to add an `ostree=` arg, so we need to tolerate this.
So this assertion would fail there. Restore the behaviour prior to b9ce0e89 and re-add a more contemporary comment.
Fixes b9ce0e89 ("generator: Exit if there's no `/run/ostree`").
Timothée Ravier [Wed, 31 Jan 2024 14:38:31 +0000 (15:38 +0100)]
grub2-15_ostree: Graceful exit if /etc/default/grub doesn't exist
With the new bootupd installation path in Anaconda, the
`/etc/default/grub` config file is not written anymore as we are only
using BLS configs with new enough bootloaders.
We thus don't need to generate (duplicated) legacy boot entries.
We still need to keep this logic in place in Atomic Desktops
(Silverblue, etc.) until we've actually landed bootupd there and forced
a bootloader update for everybody.
This generates the new format for whiteout markers which was added in
6.8 (and which will be backported to 6.7). Without this whiteouts
will not work anymore.
This is a slight format change, but will only affect ostree commits
that already were broken (i.e that had whiteouts), and since the
composefs code is still marked experimental I think it is fine to
do this without introducing another format version on the ostree
side.
Signed-off-by: Alexander Larsson <alexl@redhat.com>
projects / ostree.git / log